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MPLS Transport Profile (MPLS-TP) Control Plane Framework 
Abstract 


The MPLS Transport Profile (MPLS-TP) supports static provisioning of 
transport paths via a Network Management System (NMS) and dynamic 
provisioning of transport paths via a control plane. This document 
provides the framework for MPLS-TP dynamic provisioning and covers 
control-plane addressing, routing, path computation, signaling, 
traffic engineering, and path recovery.  MPLS-TP uses GMPLS as the 
control plane for MPLS-TP Label Switched Paths (LSPs).  MPLS-TP also 
uses the pseudowire (PW) control plane for pseudowires.  Management- 
plane functions are out of scope of this document. 


This document is a product of a joint Internet Engineering Task Force 
(IETF) / International Telecommunication Union Telecommunication 
Standardization Sector (ITU-T) effort to include an MPLS Transport 
Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge 
(PWE3) architectures to support the capabilities and functionalities 
of a packet transport network as defined by the ITU-T. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 
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and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6373. 
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1. Introduction 


The Multiprotocol Label Switching Transport Profile (MPLS-TP) is 
defined as a joint effort between the International Telecommunication 
Union (ITU) and the IETF. The requirements for MPLS-TP are defined 


in the requirements document, see [RFC5654]. These requirements 
state that "A solution MUST be defined to support dynamic 
provisioning of MPLS-TP transport paths via a control plane". This 


document provides the framework for such dynamic provisioning. This 
document is a product of a joint Internet Engineering Task Force 
(IETF) / International Telecommunication Union Telecommunication 
Standardization Sector (ITU-T) effort to include an MPLS Transport 
Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge 
(PWE3) architectures to support the capabilities and functions of a 
packet transport network as defined by the ITU-T. 
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1.1. Scope 


This document covers the control-plane functions involved in 
establishing MPLS-TP Label Switched Paths (LSPs) and pseudowires 
(PWs). The control-plane requirements for MPLS-TP are defined in the 
MPLS-TP requirements document [RFC5654]. These requirements define 
the role of the control plane in MPLS-TP. In particular, Section 2.4 
of [RFC5654] and portions of the remainder of Section 2 of [RFC5654] 
provide specific control-plane requirements. 


The LSPs provided by MPLS-TP are used as a server layer for IP, MPLS, 
and PWs, as well as other tunneled MPLS-TP LSPs. The PWs are used to 


carry client signals other than IP or MPLS. The relationship between 
PWs and MPLS-TP LSPs is exactly the same as between PWs and MPLS LSPs 
in an MPLS Packet Switched Network (PSN). The PW encapsulation over 


MPLS-TP LSPs used in MPLS-TP networks is also the same as for PWs 
over MPLS in an MPLS network.  MPLS-TP also defines protection and 
restoration (or, collectively, recovery) functions; see [RFC5654] and 
[RFC4427]. The MPLS-TP control plane provides methods to establish, 
remove, and control MPLS-TP LSPs and PWs. This includes control of 
Operations, Administration, and Maintenance (OAM), data-plane, and 
recovery functions. 


A general framework for MPLS-TP has been defined in [RFC5921], anda 
survivability framework for MPLS-TP has been defined in [RFC6372]. 
These documents scope the approaches and protocols that are the 
foundation of MPLS-TP. Notably, Section 3.5 of [RFC5921] scopes the 
IETF protocols that serve as the foundation of the MPLS-TP control 
plane. The PW control plane is based on the existing PW control 
plane (see [RFC4447]) and the PWE3 architecture (see [RFC3985]). The 
LSP control plane is based on GMPLS (see [RFC3945]), which is built 
on MPLS Traffic Engineering (TE) and its numerous extensions. 
[RFC6372] focuses on the recovery functions that must be supported 
within MPLS-TP. It does not specify which control-plane mechanisms 
are to be used. 


The remainder of this document discusses the impact of the MPLS-TP 
requirements on the GMPLS signaling and routing protocols that are 
used to control MPLS-TP LSPs, and on the control of PWs as specified 
in [RFC4447], [RFC6073], and [MS-PW-DYNAMIC]. 


1.2. Basic Approach 


The basic approach taken in defining the MPLS-TP control-plane 
framework includes the following: 


1) MPLS technology as defined by the IETF is the foundation for 
the MPLS Transport Profile. 
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2) The data plane for MPLS-TP is a standard MPLS data plane 
[RFC3031] as profiled in [RFC5960]. 


3) MPLS PWs are used by MPLS-TP including the use of targeted 
Label Distribution Protocol (LDP) as the foundation for PW 
Signaling [RFC4447]. This also includes the use of Open 
Shortest Path First with Traffic Engineering (OSPF-TE), 
Intermediate System to Intermediate System (IS-IS) with Traffic 
Engineering (ISIS-TE), or Multiprotocol Border Gateway Protocol 
(MP-BGP) as they apply for Multi-Segment Pseudowire (MS-PW) 
routing. However, the PW can be encapsulated over an MPLS-TP 
LSP (established using methods and procedures for MPLS-TP LSP 
establishment) in addition to the presently defined methods of 
carrying PWs over LSP-based PSNs. That is, the MPLS-TP domain 
is a PSN from a PWE3 architecture perspective [RFC3985]. 


4) The MPLS-TP LSP control plane builds on the GMPLS control plane 
as defined by the IETF for transport LSPs. The protocols 
within scope are Resource Reservation Protocol with Traffic 
Engineering (RSVP-TE) [RFC3473], OSPF-TE [RFC4203] [RFC5392], 
and ISIS-TE [RFC5307] [RFC5316]. Automatically Switched 
Optical Network (ASON) signaling and routing requirements in 
the context of GMPLS can be found in [RFC4139] and [RFC4258]. 


5) Existing IETF MPLS and GMPLS RFCs and evolving Working Group 
Internet-Drafts should be reused wherever possible. 


6) If needed, extensions for the MPLS-TP control plane should 
first be based on the existing and evolving IETF work, and 
secondly be based on work by other standard bodies only when 
IETF decides that the work is out of the IETF’s scope. New 
extensions may be defined otherwise. 


7) Extensions to the control plane may be required in order to 
fully automate functions related to MPLS-TP LSPs and PWs. 


8) Control-plane software upgrades to existing equipment are 
acceptable and expected. 


9) It is permissible for functions present in the GMPLS and PW 
control planes to not be used in MPLS-TP networks. 


10) One possible use of the control plane is to configure, enable, 
and generally control OAM functionality. This will require 
extensions to existing control-plane specifications that will 
be usable in MPLS-TP as well as MPLS networks. 
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1. 


3. 


11) The foundation for MPLS-TP control-plane requirements is 
primarily found in Section 2.4 of [RFC5654] and relevant 
portions of the remainder of Section 2 of [RFC5654]. 


Reference Model 


The control-plane reference model is based on the general MPLS-TP 
reference model as defined in the MPLS-TP framework [RFC5921] and 
further refined in [RFC6215] on the MPLS-TP User-to-Network and 
Network-to-Network Interfaces (UNI and NNI, respectively). Per the 
MPLS-TP framework [RFC5921], the MPLS-TP control plane is based on 
GMPLS with RSVP-TE for LSP signaling and targeted LDP for PW 
signaling. In both cases, OSPF-TE or ISIS-TE with GMPLS extensions 
is used for dynamic routing within an MPLS-TP domain. 


Note that in this context, "targeted LDP" (or T-LDP) means LDP as 


defined in RFC 5036, using Targeted Hello messages. See Section 

2.4.2 ("Extended Discovery Mechanism") of [RFC5036]. Use of the 

extended discovery mechanism is specified in Section 5 ("LDP") of 
[RFC4447]. 


From a service perspective, MPLS-TP client services may be supported 
via both PWs and LSPs. PW client interfaces, or adaptations, are 
defined on an interface-technology basis, e.g., Ethernet over PW 
[RFC4448]. In the context of MPLS-TP LSP, the client interface is 
provided at the network layer and may be controlled via a GMPLS-based 
UNI, see [RFC4208], or statically provisioned. As discussed in 
[RFC5921] and [RFC6215], MPLS-TP also presumes an NNI reference 
point. 


The MPLS-TP end-to-end control-plane reference model is shown in 
Figure 1. The figure shows the control-plane protocols used by MPLS- 
TP, as well as the UNI and NNI reference points, in the case of a 
Single-Segment PW supported by an end-to-end LSP without any 
hierarchical LSPs. (The MS-PW case is not shown.) Each service 
provider node's participation in routing and signaling (both GMPLS 
RSVP-TE and PW LDP) is represented. Note that only the service end 
points participate in PW LDP signaling, while all service provider 
nodes participate in GMPLS TE LSP routing and signaling. 
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|< ---- client signal (e.g., IP / MPLS / L2) -------- >| 
|< --------- SP1 ---------- >|< ------- SP2 ----- >| 
|< ---------- MPLS-TP End-to-End PW --------- >| 
|< -------- MPLS-TP End-to-End LSP ------ >| 


+---+ +--+ +--+ +--+ +--+ +--+ +---+ +---+ +--+ 


|cE1|-|-|pz1|--|P1 |--|P2 |--|PE2|-|-|Pza|--|Pa |--|PEb|-|-|CcE2| 
4+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 4+---+ 
UNI NNI UNI 
GMPLS 
TE-RTG,  |«-----|------]|------]|-------]|------|----- > | 
& RSVP-TE 
PW LDP |< ---------------------------------------- > | 


Figure 1. End-to-End MPLS-TP Control-Plane Reference Model 


Legend: 

CE: Customer Edge 

Client signal: defined in MPLS-TP Requirements 

L2: Any layer 2 signal that may be carried 
over a PW, e.g., Ethernet 

NNI: Network-to-Network Interface 

P: Provider 

PE: Provider Edge 

SP: Service Provider 

TE-RTG: GMPLS OSPF-TE or ISIS-TE 

UNI: User-to-Network Interface 


Note: The MS-PW case is not shown. 


Figure 2 adds three hierarchical LSP segments, labeled as "H-LSPs". 
These segments are present to support scaling, OAM, and Maintenance 
Entity Group End Points (MEPs), see [RFC6371], within each provider 
domain and across the inter-provider NNI. (H-LSPs are used to 
implement Sub-Path Maintenance Elements (SPMEs) as defined in 
[RFC5921].) The MEPs are used to collect performance information, 
support diagnostic and fault management functions, and support OAM 
triggered survivability schemes as discussed in [RFC6372]. Each 
H-LSP may be protected or restored using any of the schemes discussed 
in [RFC6372].  End-to-end monitoring is supported via MEPs at the 
end-to-end LSP and PW end points. Note that segment MEPs may be co- 
located with MIPs of the next higher-layer (e.g., end-to-end) LSPs. 
(The MS-PW case is not shown.) 
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|< ------- client signal (e.g., IP / MPLS / L2) ----- > | 
|< -------- SP1 ----------- >|< ------- SP2 ----- > | 
|< ----------- MPLS-TP End-to-End PW -------- > | 
|< ------- MPLS-TP End-to-End LSP ------- > | 
|< -- H-LSP1 ---- >|<-H-LSP2->|<- H-LSP3 ->| 


+---+  +---+ ---—4 4---4 +---+ +--+ +---+ +---+ +--+ 


|cz1|-|-|ez1|--|p1 |--|P2 |--|rE2|-|-|PEaļ|--|Pa |--|PEb|-|-|CcE2| 

+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 4+---+ 
UNI NNI UNI 

megaa |e | see Sse ee 

PW OAM OF Fee CF TF 

End2end |uep|---------------- jute -- [mtb |---------juse| 

LSP OAM frr. Ye ia Aa dee a Frrvv PET FE 


Segment |MEP|-|MIP|-|MmIP |- |MEP |MEP | - | MEP |MEP | - |ur» |- | MEP | 


LSP OAM TETE FETTET Frrvv ,yryrrrrrr FEET REE LT FETTET FETTET 


H-LSP GMPLS 
TE-RTG |<-----|------|----- >| |<----> | |<-----|----- > 
&RSVP-TE (within an MPLS-TP network) 


E2E GMPLS 
TE-RTG = |< ------------------ | -------- | ------------ > | 
&RSVP-TE 

PW LDP |< ---------------------------------------- > | 


Figure 2. MPLS-TP Control-Plane Reference Model with OAM 


Legend: 

CE: Customer Edge 

Client signal: defined in MPLS-TP Requirements 

E2E: End-to-End 

L2: Any layer 2 signal that may be carried 
over a PW, e.g., Ethernet 

H-LSP: Hierarchical LSP 

MEP: Maintenance Entity Group End Point 

MIP: Maintenance Entity Group Intermediate Point 

NNI: Network-to-Network Interface 

P: Provider 

PE: Provider Edge 

SP: Service Provider 

TE-RIG: GMPLS OSPF-TE or ISIS-TE 


Note: The MS-PW case is not shown. 
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While not shown in the figures above, the MPLS-TP control plane must 
support the addressing separation and independence between the data, 
control, and management planes. Address separation between the 
planes is already included in GMPLS. Such separation is also already 
included in LDP as LDP session end point addresses are never 
automatically associated with forwarding. 


2.  Control-Plane Requirements 


The requirements for the MPLS-TP control plane are derived from the 
MPLS-TP requirements and framework documents, specifically [RFC5654], 
[RFC5921], [RFC5860], [RFC6371], and [RFC6372]. The requirements are 
summarized in this section, but do not replace those documents. If 
there are differences between this section and those documents, those 
documents shall be considered authoritative. 


2.1. Primary Requirements 
These requirements are based on Section 2 of [RFC5654]: 


1. Any new functionality that is defined to fulfill the 
requirements for MPLS-TP must be agreed within the IETF through 
the IETF consensus process as per [RFC4929] and Section 1, 
paragraph 15 of [RFC5654]. 


2. The MPLS-TP control-plane design should as far as reasonably 
possible reuse existing MPLS standards ([RFC5654], requirement 
2). 


3. The MPLS-TP control plane must be able to interoperate with 
existing IETF MPLS and PWE3 control planes where appropriate 
([REFC5654], requirement 3). 


4. The MPLS-TP control plane must be sufficiently well-defined to 
ensure that the interworking between equipment supplied by 
multiple vendors will be possible both within a single domain 
and between domains ([RFC5654], requirement 4). 


5. The MPLS-TP control plane must support a connection-oriented 
packet switching model with traffic engineering capabilities 
that allow deterministic control of the use of network 
resources ([RFC5654], requirement 5). 


6. The MPLS-TP control plane must support traffic-engineered 


point-to-point (P2P) and point-to-multipoint (P2MP) transport 
paths ([RFC5654], requirement 6). 
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The MPLS-TP control plane must support unidirectional, 
associated bidirectional and co-routed bidirectional point-to- 
point transport paths ([RFC5654], requirement 7). 


The MPLS-TP control plane must support unidirectional point-to- 
multipoint transport paths ([RFC5654], requirement 8). 


The MPLS-TP control plane must enable all nodes (i.e., ingress, 
egress, and intermediate) to be aware about the pairing 
relationship of the forward and the backward directions 
belonging to the same co-routed bidirectional transport path 
([REC5654], requirement 10). 


The MPLS-TP control plane must enable edge nodes (i.e., ingress 
and egress) to be aware of the pairing relationship of the 
forward and the backward directions belonging to the same 
associated bidirectional transport path ([RFC5654], requirement 
11). 


The MPLS-TP control plane should enable common transit nodes to 
be aware of the pairing relationship of the forward and the 
backward directions belonging to the same associated 
bidirectional transport path ([RFC5654], requirement 12). 


The MPLS-TP control plane must support bidirectional transport 
paths with symmetric bandwidth requirements, i.e., the amount 
of reserved bandwidth is the same in the forward and backward 
directions ([RFC5654], requirement 13). 


The MPLS-TP control plane must support bidirectional transport 
paths with asymmetric bandwidth requirements, i.e., the amount 
of reserved bandwidth differs in the forward and backward 
directions ([RFC5654], requirement 14). 


The MPLS-TP control plane must support the logical separation 
of the control plane from the management and data planes 
([RFC5654], requirement 15). Note that this implies that the 
addresses used in the control plane are independent from the 
addresses used in the management and data planes. 


The MPLS-TP control plane must support the physical separation 
of the control plane from the management and data plane, and no 
assumptions should be made about the state of the data-plane 
channels from information about the control- or management- 
plane channels when they are running out-of-band ([RFC5654], 
requirement 16). 
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18. 


19. 


20. 


21- 


22. 


23. 


24. 


25. 


26. 
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A control plane must be defined to support dynamic provisioning 
and restoration of MPLS-TP transport paths, but its use is a 
network operator's choice ([RFC5654], requirement 18). 


The presence of a control plane must not be required for static 
provisioning of MPLS-TP transport paths ([RFC5654], requirement 
19). 


The MPLS-TP control plane must permit the coexistence of 
statically and dynamically provisioned/managed MPLS-TP 
transport paths within the same layer network or domain 
([REC5654], requirement 20). 


The MPLS-TP control plane should be operable in a way that is 
similar to the way the control plane operates in other 
transport-layer technologies ([RFC5654], requirement 21). 


The MPLS-TP control plane must avoid or minimize traffic impact 
(e.g., packet delay, reordering, and loss) during network 
reconfiguration ([RFC5654], requirement 24). 


The MPLS-TP control plane must work across multiple homogeneous 
domains ([RFC5654], requirement 25), i.e., all domains use the 
same MPLS-TP control plane. 


The MPLS-TP control plane should work across multiple non- 
homogeneous domains ([RFC5654], requirement 26), i.e., some 
domains use the same control plane and other domains use static 
provisioning at the domain boundary. 


The MPLS-TP control plane must not dictate any particular 
physical or logical topology ([RFC5654], requirement 27). 


The MPLS-TP control plane must include support of ring 
topologies that may be deployed with arbitrary interconnection 
and support of rings of at least 16 nodes ([RFC5654], 
requirements 27.A, 27.B, and 27.C). 


The MPLS-TP control plane must scale gracefully to support a 
large number of transport paths, nodes, and links. That is, it 
must be able to scale at least as well as control planes in 
existing transport technologies with growing and increasingly 
complex network topologies as well as with increasing bandwidth 
demands, number of customers, and number of services 
([REC5654], requirements 53 and 28). 


The MPLS-TP control plane should not provision transport paths 
that contain forwarding loops ([RFC5654], requirement 29). 
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29. 


30. 


231. 


32. 


33. 


34. 
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The MPLS-TP control plane must support multiple client layers 
(e.g., MPLS-TP, IP, MPLS, Ethernet, ATM, Frame Relay, etc.) 
([REC5654], requirement 30). 


The MPLS-TP control plane must provide a generic and extensible 
solution to support the transport of MPLS-TP transport paths 
over one or more server-layer networks (such as MPLS-TP, 
Ethernet, Synchronous Optical Network / Synchronous Digital 
Hierarchy (SONET/SDH), Optical Transport Network (OTN), etc.). 
Requirements for bandwidth management within a server-layer 
network are outside the scope of this document ([RFC5654], 
requirement 31). 


In an environment where an MPLS-TP layer network is supporting 
a client-layer network, and the MPLS-TP layer network is 
supported by a server-layer network, then the control-plane 
operation of the MPLS-TP layer network must be possible without 
any dependencies on the server or client-layer network 
([REC5654], requirement 32). 


The MPLS-TP control plane must allow for the transport of a 
client MPLS or MPLS-TP layer network over a server MPLS or 
MPLS-TP layer network ([RFC5654], requirement 33). 


The MPLS-TP control plane must allow the autonomous operation 
of the layers of a multi-layer network that includes an MPLS-TP 
layer ([RFC5654], requirement 34). 


The MPLS-TP control plane must allow the hiding of MPLS-TP 
layer network addressing and other information (e.g., topology) 
from client-layer networks. However, it should be possible, at 
the option of the operator, to leak a limited amount of 
summarized information, such as Shared Risk Link Groups (SRLGs) 
or reachability, between layers ([RFC5654], requirement 35). 


The MPLS-TP control plane must allow for the identification of 
a transport path on each link within and at the destination 
(egress) of the transport network ([RFC5654], requirements 38 
and 39). 


The MPLS-TP control plane must allow for the use of P2MP server 
(sub-)layer capabilities as well as P2P server (sub-)layer 
capabilities when supporting P2MP MPLS-TP transport paths 
([REC5654], requirement 40). 


The MPLS-TP control plane must be extensible in order to 
accommodate new types of client-layer networks and services 
([REC5654], requirement 41). 
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The MPLS-TP control plane should support the reserved bandwidth 
associated with a transport path to be increased without 
impacting the existing traffic on that transport path, provided 
enough resources are available ([RFC5654], requirement 42)). 


The MPLS-TP control plane should support the reserved bandwidth 
of a transport path being decreased without impacting the 
existing traffic on that transport path, provided that the 
level of existing traffic is smaller than the reserved 
bandwidth following the decrease ([RFC5654], requirement 43). 


The control plane for MPLS-TP must fit within the ASON 


(control-plane) architecture. The ITU-T has defined an 
architecture for ASONs in G.8080 [ITU.G8080.2006] and G.8080 
Amendment 1 [ITU.G8080.2008]. An interpretation of the ASON 


signaling and routing requirements in the context of GMPLS can 
be found in [RFC4139], [RFC4258], and Section 2.4, paragraphs 2 
and 3 of [RFC5654]. 


The MPLS-TP control plane must support control-plane topology 
and data-plane topology independence ([RFC5654], requirement 
47). 


A failure of the MPLS-TP control plane must not interfere with 
the delivery of service or recovery of established transport 
paths ([RFC5654], requirement 47). 


The MPLS-TP control plane must be able to operate independent 
of any particular client- or server-layer control plane 
([REC5654], requirement 48). 


The MPLS-TP control plane should support, but not require, an 
integrated control plane encompassing MPLS-TP together with its 
server- and client-layer networks when these layer networks 
belong to the same administrative domain ([RFC5654], 
requirement 49). 


The MPLS-TP control plane must support configuration of 
protection functions and any associated maintenance (OAM) 
functions ([RFC5654], requirements 50 and 7). 


The MPLS-TP control plane must support the configuration and 
modification of OAM maintenance points as well as the 
activation/deactivation of OAM when the transport path or 
transport service is established or modified ([RFC5654], 
requirement 51). 
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The MPLS-TP control plane must be capable of restarting and 
relearning its previous state without impacting forwarding 
([RFC5654], requirement 54). 


The MPLS-TP control plane must provide a mechanism for dynamic 
ownership transfer of the control of MPLS-TP transport paths 
from the management plane to the control plane and vice versa. 
The number of reconfigurations required in the data plane must 
be minimized; preferably no data-plane reconfiguration will be 
required ([RFC5654], requirement 55). Note, such transfers 
cover all transport path control functions including control of 
recovery and OAM. 


The MPLS-TP control plane must support protection and 
restoration mechanisms, i.e., recovery ([RFC5654], requirement 
52). 


Note that the MPLS-TP survivability framework document 
[RFC6372] provides additional useful information related to 
recovery. 


The MPLS-TP control-plane mechanisms should be identical (or as 
similar as possible) to those already used in existing 
transport networks to simplify implementation and operations. 
However, this must not override any other requirement 
([REC5654], requirement 56 A). 


The MPLS-TP control-plane mechanisms used for P2P and P2MP 
recovery should be identical to simplify implementation and 
operation. However, this must not override any other 
requirement ([RFC5654], requirement 56 B). 


The MPLS-TP control plane must support recovery mechanisms that 
are applicable at various levels throughout the network 
including support for link, transport path, segment, 
concatenated segment, and end-to-end recovery ([RFC5654], 
requirement 57). 


The MPLS-TP control plane must support recovery paths that meet 
the Service Level Agreement (SLA) protection objectives of the 


service ([RFC5654], requirement 58). These include: 


a. Guarantee 50-ms recovery times from the moment of fault 
detection in networks with spans less than 1200 km. 


b. Protection of 100$ of the traffic on the protected path. 


C. Recovery must meet SLA requirements over multiple domains. 
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The MPLS-TP control plane should support per-transport-path 
recovery objectives ([RFC5654], requirement 59). 


The MPLS-TP control plane must support recovery mechanisms that 
are applicable to any topology ([RFC5654], requirement 600). 


The MPLS-TP control plane must operate in synergy with 
(including coordination of timing/timer settings) the recovery 
mechanisms present in any client or server transport networks 
(for example, Ethernet, SDH, OTN, Wavelength Division 
Multiplexing (WDM)) to avoid race conditions between the layers 
([REC5654], requirement 61). 


The MPLS-TP control plane must support recovery and reversion 
mechanisms that prevent frequent operation of recovery in the 
event of an intermittent defect ([RFC5654], requirement 62). 


The MPLS-TP control plane must support revertive and non- 
revertive protection behavior ([RFC5654], requirement 604). 


The MPLS-TP control plane must support 1+1 bidirectional 
protection for P2P transport paths ([RFC5654], requirement 65 
A). 


The MPLS-TP control plane must support 1+1 unidirectional 
protection for P2P transport paths ([RFC5654], requirement 65 
B). 


The MPLS-TP control plane must support 1+1 unidirectional 
protection for P2MP transport paths ([RFC5654], requirement 65 
Cy« 


The MPLS-TP control plane must support the ability to share 
protection resources amongst a number of transport paths 
([REC5654], requirement 66). 


The MPLS-TP control plane must support 1:n bidirectional 
protection for P2P transport paths.  Bidirectional 1:n 
protection should be the default for 1:n protection ([RFC5654], 
requirement 67 A). 


The MPLS-TP control plane must support 1:n unidirectional 
protection for P2MP transport paths ([RFC5654], requirement 67 
B). 


The MPLS-TP control plane may support 1:n unidirectional 
protection for P2P transport paths ([RFC5654], requirement 65 
x 
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The MPLS-TP control plane may support the control of extra- 
traffic type traffic ([RFC5654], note after requirement 607). 


The MPLS-TP control plane should support 1:n (including 1:1) 
shared mesh recovery ([RFC5654], requirement 68). 


The MPLS-TP control plane must support sharing of protection 
resources such that protection paths that are known not to be 
required concurrently can share the same resources ([RFC5654], 
requirement 69). 


The MPLS-TP control plane must support the sharing of resources 
between a restoration transport path and the transport path 
being replaced ([RFC5654], requirement 70). 


The MPLS-TP control plane must support restoration priority so 
that an implementation can determine the order in which 
transport paths should be restored ([RFC5654], requirement 71). 


The MPLS-TP control plane must support preemption priority in 
order to allow restoration to displace other transport paths in 
the event of resource constraints ([RFC5654], requirements 72 
and 86). 


The MPLS-TP control plane must support revertive and non- 
revertive restoration behavior ([RFC5654], requirement 73). 


The MPLS-TP control plane must support recovery being triggered 
by physical (lower) layer fault indications ([RFC5654], 
requirement 74). 


The MPLS-TP control plane must support recovery being triggered 
by OAM ([RFC5654], requirement 75). 


The MPLS-TP control plane must support management-plane 
recovery triggers (e.g., forced switch, etc.) ([RFC5654], 
requirement 76). 


The MPLS-TP control plane must support the differentiation of 
administrative recovery actions from recovery actions initiated 
by other triggers ([RFC5654], requirement 77). 


The MPLS-TP control plane should support control-plane 
restoration triggers (e.g., forced switch, etc.) ([RFC5654], 
requirement 78). 
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76. The MPLS-TP control plane must support priority logic to 
negotiate and accommodate coexisting requests (i.e., multiple 
requests) for protection switching (e.g., administrative 
requests and requests due to link/node failures) ([RFC5654], 
requirement 79). 


77. The MPLS-TP control plane must support the association of 
protection paths and working paths (sometimes known as 
protection groups) ([RFC5654], requirement 80). 


78. The MPLS-TP control plane must support pre-calculation of 
recovery paths ([RFC5654], requirement 81). 


79. The MPLS-TP control plane must support pre-provisioning of 
recovery paths ([RFC5654], requirement 82). 


80. The MPLS-TP control plane must support the external commands 
defined in [RFCA4427]. External controls overruled by higher 
priority requests (e.g., administrative requests and requests 
due to link/node failures) or unable to be signaled to the 
remote end (e.g., because of a protection state coordination 
fail) must be ignored/dropped ([RFC5654], requirement 83). 


81. The MPLS-TP control plane must permit the testing and 
validation of the integrity of the protection/recovery 
transport path ([RFC5654], requirement 84 A). 


82. The MPLS-TP control plane must permit the testing and 
validation of protection/restoration mechanisms without 
triggering the actual protection/restoration ([RFC5654], 
requirement 84 B). 


83. The MPLS-TP control plane must permit the testing and 
validation of protection/restoration mechanisms while the 
working path is in service ([RFC5654], requirement 84 C). 


84. The MPLS-TP control plane must permit the testing and 
validation of protection/restoration mechanisms while the 
working path is out of service ([RFC5654], requirement 84 D). 


85. The MPLS-TP control plane must support the establishment and 
maintenance of all recovery entities and functions ([RFC5654], 


requirement 89 A). 


86. The MPLS-TP control plane must support signaling of recovery 
administrative control ([RFC5654], requirement 89 B). 


Andersson, et al. Informational [Page 17] 


RFC 6373 MPLS-TP Control Plane Framework September 2011 


87. The MPLS-TP control plane must support protection state 
coordination. Since control-plane network topology is 
independent from the data-plane network topology, the 
protection state coordination supported by the MPLS-TP control 
plane may run on resources different than the data-plane 
resources handled within the recovery mechanism (e.g., backup) 
([REC5654], requirement 89 C). 


88. When present, the MPLS-TP control plane must support recovery 
mechanisms that are optimized for specific network topologies. 
These mechanisms must be interoperable with the mechanisms 
defined for arbitrary topology (mesh) networks to enable 
protection of end-to-end transport paths ([RFC5654], 
requirement 91). 


89. When present, the MPLS-TP control plane must support the 
control of ring-topology-specific recovery mechanisms 
([RFC5654], Section 2.5.6.1). 


90. The MPLS-TP control plane must include support for 
differentiated services and different traffic types with 
traffic class separation associated with different traffic 
([REC5654], requirement 110). 


91. The MPLS-TP control plane must support the provisioning of 
services that provide guaranteed Service Level Specifications 
(SLSs), with support for hard ([RFC3209] style) and relative 
([RFC3270] style) end-to-end bandwidth guarantees ([RFC5654], 
requirement 111). 


92. The MPLS-TP control plane must support the provisioning of 
services that are sensitive to jitter and delay ([RFC5654], 
requirement 112). 


2.2. Requirements Derived from the MPLS-TP Framework 


The following additional requirements are based on [RFC5921], 
[TP-P2MP-FWK], and [RFC5960]: 


93. Per-packet Equal Cost Multi-Path (ECMP) load balancing is 
currently outside the scope of MPLS-TP ([RFC5960], Section 
3.1.1, paragraph 6). 


94. Penultimate Hop Popping (PHP) must be disabled on MPLS-TP LSPs 
by default ([RFC5960], Section 3.1.1, paragraph 7). 
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95. The MPLS-TP control plane must support both E-LSP (Explicitly 
TC-encoded-PSC LSP) and L-LSP (Label-Only-Inferred-PSC LSP) 
MPLS Diffserv modes as specified in [RFC3270], [RFC5462], and 
Section 3.3.2, paragraph 12 of [RFC5960]. 


96. Both Single-Segment PWs (see [RFC3985]) and Multi-Segment PWs 
(see [RFC5659]) shall be supported by the MPLS-TP control 
plane. MPLS-TP shall use the definition of Multi-Segment PWs 
as defined by the IETF ([RFC5921], Section 3.4.4). 


97. The MPLS-TP control plane must support the control of PWs and 
their associated labels ([RFC5921], Section 3.4.4). 


98. The MPLS-TP control plane must support network-layer clients, 
i.e., clients whose traffic is transported over an MPLS-TP 
network without the use of PWs ([RFC5921], Section 3.4.5). 


a. The MPLS-TP control plane must support the use of network- 
layer protocol-specific LSPs and labels ([RFC5921], Section 
3:45) 


b. The MPLS-TP control plane must support the use of a client- 
Service-specific LSPs and labels ([RFC5921], Section 3.4.5). 


99. The MPLS-TP control plane for LSPs must be based on the GMPLS 
control plane. More specifically, GMPLS RSVP-TE [RFC3473] and 
related extensions are used for LSP signaling, and GMPLS OSPF- 
TE [RFC5392] and ISIS-TE [RFC5316] are used for routing 
([RFC5921], Section 3.9). 


100. The MPLS-TP control plane for PWs must be based on the MPLS 
control plane for PWs, and more specifically, targeted LDP (T- 
LDP) [RFC4447] is used for PW signaling ([RFC5921], Section 
3.9, paragraph 5). 


101. The MPLS-TP control plane must ensure its own survivability and 
be able to recover gracefully from failures and degradations. 
These include graceful restart and hot redundant configurations 
([REC5921], Section 3.9, paragraph 16). 


102. The MPLS-TP control plane must support linear, ring, and meshed 
protection schemes ([RFC5921], Section 3.12, paragraph 3). 


103. The MPLS-TP control plane must support the control of SPMEs 


(hierarchical LSPs) for new or existing end-to-end LSPs 
([REC5921], Section 3.12, paragraph 7). 
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2.3. Requirements Derived from the OAM Framework 


The following additional requirements are based on [RFC5860] and 
[RFC6371]: 


104. The MPLS-TP control plane must support the capability to 
enable/disable OAM functions as part of service establishment 
([REC5860], Section 2.1.6, paragraph 1. Note that OAM 
functions are applicable regardless of the label stack depth 
(i.e., level of LSP hierarchy or PW) ([RFC5860], Section 2.1.1, 
paragraph 3). 


105. The MPLS-TP control plane must support the capability to 
enable/disable OAM functions after service establishment. In 
such cases, the customer must not perceive service degradation 
as a result of OAM enabling/disabling ([RFC5860], Section 
2.1.6, paragraphs 1 and 2). 


106. The MPLS-TP control plane must support dynamic control of any 
of the existing IP/MPLS and PW OAM protocols, e.g., LSP-Ping 
[RFC4379], MPLS-BFD [RFC5884], VCCV [RFC5085], and VCCV-BFD 
[RFC5885] ([RFC5860], Section 2.1.4, paragraph 2). 


107. The MPLS-TP control plane must allow for the ability to support 
experimental OAM functions. These functions must be disabled 
by default ([RFC5860], Section 2.2, paragraph 2). 


108. The MPLS-TP control plane must support the choice of which (if 
any) OAM function(s) to use and to which PW, LSP or Section it 
applies ([RFC5860], Section 2.2, paragraph 3). 


109. The MPLS-TP control plane must allow (e.g., enable/disable) 
mechanisms that support the localization of faults and the 
notification of appropriate nodes ([RFC5860], Section 2.2.1, 
paragraph 1). 


110. The MPLS-TP control plane may support mechanisms that permit 
the service provider to be informed of a fault or defect 
affecting the service(s) it provides, even if the fault or 
defect is located outside of his domain ([RFC5860], Section 
2.2.1, paragraph 2). 


111. Information exchange between various nodes involved in the 
MPLS-TP control plane should be reliable such that, for 
example, defects or faults are properly detected or that state 
changes are effectively known by the appropriate nodes 
([REC5860], Section 2.2.1, paragraph 3). 
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The MPLS-TP control plane must provide functionality to control 
an end point's ability to monitor the liveness of a PW, LSP, or 
Section ([RFC5860], Section 2.2.2, paragraph 1). 


The MPLS-TP control plane must provide functionality to control 
an end point's ability to determine whether or not it is 
connected to specific end point(s) by means of the expected PW, 
LSP, or Section ([RFC5860], Section 2.2.3, paragraph 1). 


a. The MPLS-TP control plane must provide mechanisms to control 
an end point's ability to perform this function proactively 
([REC5860], Section 2.2.3, paragraph 2). 


b. The MPLS-TP control plane must provide mechanisms to control 
an end point's ability to perform this function on-demand 
([REC5860], Section 2.2.3, paragraph 3). 


The MPLS-TP control plane must provide functionality to control 
diagnostic testing on a PW, LSP or Section ([RFC5860], Section 
2.2.5, paragraph 1). 


a. The MPLS-TP control plane must provide mechanisms to control 
the performance of this function on-demand ([RFC5860], 
Section 2.2.5, paragraph 2). 


The MPLS-TP control plane must provide functionality to enable 
an end point to discover the Intermediate Point(s) (if any) and 
end point(s) along a PW, LSP, or Section, and more generally to 
trace (record) the route of a PW, LSP, or Section ([RFC5860], 
Section 2.2.4, paragraph 1). 


a. The MPLS-TP control plane must provide mechanisms to control 
the performance of this function on-demand ([RFC5860], 
Section 2.2.4, paragraph 2). 


The MPLS-TP control plane must provide functionality to enable 
an end point of a PW, LSP, or Section to instruct its 
associated end point(s) to lock the PW, LSP, or Section 
([REC5860], Section 2.2.6, paragraph 1). 


a. The MPLS-TP control plane must provide mechanisms to control 
the performance of this function on-demand ([RFC5860], 
Section 2.2.6, paragraph 2). 
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The MPLS-TP control plane must provide functionality to enable 
an Intermediate Point of a PW or LSP to report, to an end point 
of that same PW or LSP, a lock condition indirectly affecting 
that PW or LSP ([RFC5860], Section 2.2.7, paragraph 1). 


a. The MPLS-TP control plane must provide mechanisms to control 
the performance of this function proactively ([RFC5860], 
Section 2.2.7, paragraph 2). 


The MPLS-TP control plane must provide functionality to enable 
an Intermediate Point of a PW or LSP to report, to an end point 
of that same PW or LSP, a fault or defect condition affecting 
that PW or LSP ([RFC5860], Section 2.2.8, paragraph 1). 


a. The MPLS-TP control plane must provide mechanisms to control 
the performance of this function proactively ([RFC5860], 
Section 2.2.8, paragraph 2). 


The MPLS-TP control plane must provide functionality to enable 
an end point to report, to its associated end point, a fault or 
defect condition that it detects on a PW, LSP, or Section for 
which they are the end points ([RFC5860], Section 2.2.9, 
paragraph 1). 


a. The MPLS-TP control plane must provide mechanisms to control 
the performance of this function proactively ([RFC5860], 
Section 2.2.9, paragraph 2). 


The MPLS-TP control plane must provide functionality to enable 
the propagation, across an MPLS-TP network, of information 
pertaining to a client defect or fault condition detected at an 
end point of a PW or LSP, if the client-layer mechanisms do not 
provide an alarm notification/propagation mechanism ([RFC5860], 
Section 2.2.10, paragraph 1). 


a. The MPLS-TP control plane must provide mechanisms to control 
the performance of this function proactively ([RFC5860], 
Section 2.2.10, paragraph 2). 


The MPLS-TP control plane must provide functionality to enable 
the control of quantification of packet loss ratio over a PW, 
LSP, or Section ([RFC5860], Section 2.2.11, paragraph 1). 


a. The MPLS-TP control plane must provide mechanisms to control 
the performance of this function proactively and on-demand 
([REC5860], Section 2.2.11, paragraph 4). 
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122. The MPLS-TP control plane must provide functionality to control 
the quantification and reporting of the one-way, and if 
appropriate, the two-way, delay of a PW, LSP, or Section 
([REC5860], Section 2.2.12, paragraph 1). 


a. The MPLS-TP control plane must provide mechanisms to control 
the performance of this function proactively and on-demand 
([REC5860], Section 2.2.12, paragraph 6). 


123. The MPLS-TP control plane must support the configuration of OAM 
functional components that include Maintenance Entities (MEs) 
and Maintenance Entity Groups (MEGs) as instantiated in MEPs, 
MIPs, and SPMEs ([RFC6371], Section 3.6). 


124. For dynamically established transport paths, the control plane 
must support the configuration of OAM operations ([RFC6371], 
Section 5). 


a. The MPLS-TP control plane must provide mechanisms to 
configure proactive monitoring for a MEG at, or after, 
transport path creation time. 


b. The MPLS-TP control plane must provide mechanisms to 
configure the operational characteristics of in-band 
measurement transactions (e.g., Connectivity Verification 
(CV), Loss Measurement (LM), etc.) at MEPs (associated with 
a transport path). 


C. The MPLS-TP control plane may provide mechanisms to 
configure server-layer event reporting by intermediate 
nodes. 


d. The MPLS-TP control plane may provide mechanisms to 
configure the reporting of measurements resulting from 
proactive monitoring. 


125. The MPLS-TP control plane must support the control of the loss 
of continuity (LOC) traffic block consequent action ([RFC6371], 
Section 5.1.2, paragraph 4). 


126. For dynamically established transport paths that have a 
proactive Continuity Check and Connectivity Verification (CC-V) 
function enabled, the control plane must support the signaling 
of the following MEP configuration information ([RFC6371], 
Section 5.1.3): 


a. The MPLS-TP control plane must provide mechanisms to 
configure the MEG identifier to which the MEP belongs. 
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b. The MPLS-TP control plane must provide mechanisms to 
configure a MEP's own identity inside a MEG. 


c. The MPLS-TP control plane must provide mechanisms to 
configure the list of the other MEPs in the MEG. 


d. The MPLS-TP control plane must provide mechanisms to 
configure the CC-V transmission rate / reception period 
(covering all application types). 


The MPLS-TP control plane must provide mechanisms to configure 
the generation of Alarm Indication Signal (AIS) packets for 
each MEG ([RFC6371], Section 5.3, paragraph 9). 


The MPLS-TP control plane must provide mechanisms to configure 
the generation of Lock Report (LKR) packets for each MEG 
([REC6371], Section 5.4, paragraph 9). 


The MPLS-TP control plane must provide mechanisms to configure 
the use of proactive Packet Loss Measurement (LM), and the 
transmission rate and Per-Hop Behavior (PHB) class associated 
with the LM OAM packets originating from a MEP ([RFC6371], 
Section 5.5.1, paragraph 1). 


The MPLS-TP control plane must provide mechanisms to configure 
the use of proactive Packet Delay Measurement (DM), and the 
transmission rate and PHB class associated with the DM OAM 
packets originating from a MEP ([RFC6371], Section 5.6.1, 
paragraph 1). 


The MPLS-TP control plane must provide mechanisms to configure 
the use of Client Failure Indication (CFI), and the 
transmission rate and PHB class associated with the CFI OAM 
packets originating from a MEP ([RFC6371], Section 5.7.1, 
paragraph 1). 


The MPLS-TP control plane should provide mechanisms to control 
the use of on-demand CV packets ([RFC6371], Section 6.1). 


a. The MPLS-TP control plane should provide mechanisms to 
configure the number of packets to be transmitted/received 
in each burst of on-demand CV packets and their packet size 
([RFC6371], Section 6.1.1, paragraph 1). 


b. When an on-demand CV packet is used to check connectivity 
toward a target MIP, the MPLS-TP control plane should 
provide mechanisms to configure the number of hops to reach 
the target MIP ([RFC6371], Section 6.1.1, paragraph 2). 
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c. The MPLS-TP control plane should provide mechanisms to 
configure the PHB of on-demand CV packets ([RFC6371], 
Section 6.1.1, paragraph 3). 


The MPLS-TP control plane should provide mechanisms to control 
the use of on-demand LM, including configuration of the 
beginning and duration of the LM procedures, the transmission 
rate, and PHB associated with the LM OAM packets originating 
from a MEP ([RFC6371], Section 6.2.1). 


The MPLS-TP control plane should provide mechanisms to control 
the use of throughput estimation ([RFC6371], Section 6.3.1). 


The MPLS-TP control plane should provide mechanisms to control 
the use of on-demand DM, including configuration of the 
beginning and duration of the DM procedures, the transmission 
rate, and PHB associated with the DM OAM packets originating 
from a MEP ([RFC6371], Section 6.5.1). 


2.4. Security Requirements 


There 


are no specific MPLS-TP control-plane security requirements. 


The existing framework for MPLS and GMPLS security is documented in 
[RFC5920], and that document applies equally to MPLS-TP. 


2.5. Identifier Requirements 


The following are requirements based on [RFC6370]: 


136. 


T374 


138. 


139. 


140. 


343... 


The MPLS-TP control plane must support MPLS-TP point-to-point 
tunnel identifiers of the forms defined in Section 5.1 of 
[RFC6370]. 


The MPLS-TP control plane must support MPLS-TP LSP identifiers 
of the forms defined in Section 5.2 of [RFC6370], and the 
mappings to GMPLS as defined in Section 5.3 of [RFC6370]. 


The MPLS-TP control plane must support pseudowire path 
identifiers of the form defined in Section 6 of [RFC6370]. 


The MPLS-TP control plane must support MEG IDs for LSPs and PWs 
as defined in Section 7.1.1 of [RFC6370]. 


The MPLS-TP control plane must support IP-compatible MEG IDs 
for LSPs and PWs as defined in Section 7.1.2 of [RFC6370]. 


The MPLS-TP control plane must support MEP IDs for LSPs and PWs 
of the forms defined in Section 7.2.1 of [RFC6370]. 
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142. The MPLS-TP control plane must support IP-based MEP IDs for 
MPLS-TP LSP of the forms defined in Section 7.2.2.1 of 
[RFC6370]. 


143. The MPLS-TP control plane must support IP-based MEP IDs for 
Pseudowires of the form defined in Section 7.2.2.2 of 
[RFC6370]. 


3. Relationship of PWs and TE LSPs 


The data-plane relationship between PWs and LSPs is inherited from 
standard MPLS and is reviewed in the MPLS-TP framework [RFC5921]. 
Likewise, the control-plane relationship between PWs and LSPs is 
inherited from standard MPLS. This relationship is reviewed in this 
document. The relationship between the PW and LSP control planes in 
MPLS-TP is the same as the relationship found in the PWE3 Maintenance 
Reference Model as presented in the PWE3 architecture; see Figure 6 


of [RFC3985]. The PWE3 architecture [RFC3985] states: "The PWE3 
protocol-layering model is intended to minimize the differences 
between PWs operating over different PSN types". Additionally, PW 


control (maintenance) takes place separately from LSP signaling. 
[RFC4447] and [MS-PW-DYNAMIC] provide such extensions for the use of 
LDP as the control plane for PWs. This control can provide PW 
control without providing LSP control. 


In the context of MPLS-TP, LSP tunnel signaling is provided via GMPLS 
RSVP-TE. While RSVP-TE could be extended to support PW control much 
as LDP was extended in [RFC4447], such extensions are out of scope of 
this document. This means that the control of PWs and LSPs will 
operate largely independently. The main coordination between LSP and 
PW control will occur within the nodes that terminate PWs or PW 
segments. See Section 5.3.2 for an additional discussion on such 
coordination. 


It is worth noting that the control planes for PWs and LSPs may be 
used independently, and that one may be employed without the other. 


This translates into four possible scenarios: (1) no control plane is 
employed; (2) a control plane is used for both LSPs and PWs; (3) a 
control plane is used for LSPs, but not PWs; (4) a control plane is 


used for PWs, but not LSPs. 


The PW and LSP control planes, collectively, must satisfy the MPLS-TP 
control-plane requirements reviewed in this document. When client 
Services are provided directly via LSPs, all requirements must be 
satisfied by the LSP control plane. When client services are 
provided via PWs, the PW and LSP control planes can operate in 
combination, and some functions may be satisfied via the PW control 
plane while others are provided to PWs by the LSP control plane. For 
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example, to support the recovery functions described in [RFC6372], 
this document focuses on the control of the recovery functions at the 
LSP layer. PW-based recovery is under development at this time and 
may be used once defined. 


4. TE LSPs 


MPLS-TP uses Generalized MPLS (GMPLS) signaling and routing, see 
[RFC3945], as the control plane for LSPs. The GMPLS control plane is 
based on the MPLS control plane.  GMPLS includes support for MPLS 
labeled data and transport data planes.  GMPLS includes most of the 
transport-centric features required to support MPLS-TP LSPs. This 
section will first review the features of GMPLS relevant to MPLS-TP 
LSPs, then identify how specific requirements can be met using 
existing GMPLS functions, and will conclude with extensions that are 
anticipated to support the remaining MPLS-TP control-plane 
requirements. 


4.1. GMPLS Functions and MPLS-TP LSPs 


This section reviews how existing GMPLS functions can be applied to 
MPLS-TP. 


Zl. In-Band and Out-of-Band Control 


GMPLS supports both in-band and out-of-band control. The terms "in- 
band" and "out-of-band", in the context of this document, refer to 
the relationship of the control plane relative to the management and 
data planes. The terms may be used to refer to the control plane 
independent of the management plane, or to both of them in concert. 
The remainder of this section describes the relationship of the 
control plane to the management and data planes. 


There are multiple uses of both terms "in-band" and "out-of-band". 
The terms may relate to a channel, a path, or a network. Each of 
these can be used independently or in combination. Briefly, some 
typical usage of the terms is as follows: 


o In-band 
This term is used to refer to cases where control-plane traffic is 
sent in the same communication channel used to transport 
associated user data or management traffic. IP, MPLS, and 
Ethernet networks are all examples where control traffic is 
typically sent in-band with the data traffic. An example of this 
case in the context of MPLS-TP is where control-plane traffic is 
sent via the MPLS Generic Associated Channel (G-ACh), see 
[RFC5586], using the same LSP as controlled user traffic. 
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o Out-of-band, in-fiber (same physical connection) 
This term is used to refer to cases where control-plane traffic is 
sent using a different communication channel from the associated 
data or management traffic, and the control communication channel 
resides in the same fiber as either the management or data 
traffic. An example of this case in the context of MPLS-TP is 
where control-plane traffic is sent via the G-ACh using a 
dedicated LSP on the same link (interface) that carries controlled 
user traffic. 


o Out-of-band, aligned topology 
This term is used to refer to the cases where control-plane 
traffic is sent using a different communication channel from the 
associated data or management traffic, and the control traffic 
follows the same node-to-node path as either the data or 
management traffic. 


Such topologies are usually supported using a parallel fiber or 
other configurations where multiple data channels are available 
and one is (dynamically) selected as the control channel. An 
example of this case in the context of MPLS-TP is where control- 
plane traffic is sent along the same nodal path, but not 
necessarily the same links (interfaces), as the corresponding 
controlled user traffic. 


o Out-of-band, independent topology 
This term is used to refer to the cases where control-plane 
traffic is sent using a different communication channel from the 
associated data or management traffic, and the control traffic may 
follow a path that is completely independent of the data traffic. 


Such configurations are a superset of the other cases and do not 
preclude the use of in-fiber or aligned topology links, but 
alignment is not required. An example of this case in the context 
of MPLS-TP is where control-plane traffic is sent between 
controlling nodes using any available path and links, completely 
without regard for the path(s) taken by corresponding management 
or user traffic. 


In the context of MPLS-TP requirements, requirement 14 (see Section 2 
above) can be met using out-of-band in-fiber or aligned topology 
types of control. Requirement 15 can only be met by using out-of- 
band, independent topology.  G-ACh is likely to be used extensively 
in MPLS-TP networks to support the MPLS-TP control (and management) 
planes. 
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4.1.2. Addressing 


MPLS-TP reuses and supports the addressing mechanisms supported by 
MPLS. The MPLS-TP identifiers document (see [RFC6370]) provides 
additional context on how IP addresses are used within MPLS-TP. 

MPLS, and consequently MPLS-TP, uses the IPv4 and IPv6 address 
families to identify MPLS-TP nodes by default for network management 
and signaling purposes. The address spaces and neighbor adjacencies 
in the control, management, and data planes used in an MPLS-TP 
network may be completely separated or combined at the discretion of 
an MPLS-TP operator and based on the equipment capabilities of a 
vendor. The separation of the control and management planes from the 
data plane allows each plane to be independently addressable. Each 
plane may use addresses that are not mutually reachable, e.g., it is 
likely that the data plane will not be able to reach an address from 
the management or control planes and vice versa. Each plane may also 
use a different address family. It is even possible to reuse 
addresses in each plane, but this is not recommended as it may lead 
to operational confusion. As previously mentioned, the G-ACh 
mechanism defined in [RFC5586] is expected to be used extensively in 
MPLS-TP networks to support the MPLS-TP control (and management) 
planes. 


4.1.3. Routing 


Routing support for MPLS-TP LSPs is based on GMPLS routing.  GMPLS 
routing builds on TE routing and has been extended to support 
multiple switching technologies per [RFC3945] and [RFC4202] as well 
as multiple levels of packet switching within a single network.  IS- 
IS extensions for GMPLS are defined in [RFC5307] and [RFC5316], which 
build on the TE extensions to IS-IS defined in [RFC5305]. OSPF 
extensions for GMPLS are defined in [RFC4203] and [RFC5392], which 
build on the TE extensions to OSPF defined in [RFC3630]. The listed 
RFCs should be viewed as a starting point rather than a comprehensive 
list as there are other IS-IS and OSPF extensions, as defined in IETF 
RFCs, that can be used within an MPLS-TP network. 


4.1.4. TE LSPs and Constraint-Based Path Computation 


Both MPLS and GMPLS allow for traffic engineering and constraint- 
based path computation.  MPLS path computation provides paths for 
MPLS-TE unidirectional P2P and P2MP LSPs.  GMPLS path computation 
adds bidirectional LSPs, explicit recovery path computation, as well 
as support for the other functions discussed in this section. 


Both MPLS and GMPLS path computation allow for the restriction of 
path selection based on the use of Explicit Route Objects (EROs) and 
other LSP attributes; see [RFC3209] and [RFC3473]. In all cases, no 
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specific algorithm is standardized by the IETF. This is anticipated 
to continue to be the case for MPLS-TP LSPs. 


4.1.4.1. Relation to PCE 


Path Computation Element (PCE)-based approaches, see [RFC4655], may 
be used for path computation of a GMPLS LSP, and consequently an 
MPLS-TP LSP, across domains and in a single domain. In cases where 
PCE is used, the PCE Communication Protocol (PCEP), see [RFC5440], 
will be used to communicate PCE-related requests and responses. 
MPLS-TP-specific extensions to PCEP are currently out of scope of the 
MPLS-TP project and this document. 


4.1.5. «Signaling 


GMPLS signaling is defined in [RFC3471] and [RFC3473] and is based on 
RSVP-TE [RFC3209].  Constraint-based Routed LDP (CR-LDP) GMPLS (see 
[RFC3472]) is no longer under active development within the IETF, 
i.e., it is deprecated (see [RFC3468]) and must not be used for MPLS 
nor MPLS-TP consequently. In general, all RSVP-TE extensions that 
apply to MPLS may also be used for GMPLS and consequently MPLS-TP. 
Most notably, this includes support for P2MP signaling as defined in 
[RFC4875]. 


GMPLS signaling includes a number of MPLS-TP required functions -- 
notably, support for out-of-band control, bidirectional LSPs, and 
independent control- and data-plane fault management. There are also 
numerous other GMPLS and MPLS extensions that can be used to provide 
specific functions in MPLS-TP networks. Specific references are 
provided below. 


4.1.6. Unnumbered Links 


Support for unnumbered links (i.e., links that do not have IP 
addresses) is permitted in MPLS-TP and its usage is at the discretion 
of the network operator. Support for unnumbered links is included 
for routing using OSPF [RFC4203] and IS-IS [RFC5307], and for 
signaling in [RFC3477]. 


4.1.7. Link Bundling 


Link bundling provides a local construct that can be used to improve 
Scaling of TE routing when multiple data links are shared between 
node pairs. Link bundling for MPLS and GMPLS networks is defined in 
[RFC4201]. Link bundling may be used in MPLS-TP networks, and its 
use is at the discretion of the network operator. 
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4.1.8. Hierarchical LSPs 
This section reuses text from [RFC6107]. 


[RFC3031] describes how MPLS labels may be stacked so that LSPs may 
be nested with one LSP running through another. This concept of 
hierarchical LSPs (H-LSPs) is formalized in [RFC4206] with a set of 
protocol mechanisms for the establishment of a hierarchical LSP that 
can carry one or more other LSPs. 


[RFC4206] goes on to explain that a hierarchical LSP may carry other 
LSPs only according to their switching types. This is a function of 
the way labels are carried. Ina packet switch capable network, the 
hierarchical LSP can carry other packet switch capable LSPs using the 
MPLS label stack. 


Signaling mechanisms defined in [RFC4206] allow a hierarchical LSP to 
be treated as a single hop in the path of another LSP. This 
mechanism is also sometimes known as "non-adjacent signaling", see 
[RFC4208]. 


A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link 
created from an LSP and advertised in the same instance of the 
control plane that advertises the TE links from which the LSP is 
constructed. The LSP itself is called an FA-LSP.  FA-LSPs are 
analogous to MPLS-TP Sections as discussed in [RFC5960]. 


Thus, a hierarchical LSP may form an FA such that it is advertised as 
a TE link in the same instance of the routing protocol as was used to 
advertise the TE links that the LSP traverses. 


As observed in [RFC4206], the nodes at the ends of an FA would not 
usually have a routing adjacency. 


LSP hierarchy is expected to play an important role in MPLS-TP 
networks, particularly in the context of scaling and recovery as well 
as supporting SPMEs. 


4.1.9. LSP Recovery 


GMPLS defines RSVP-TE extensions in support for end-to-end GMPLS LSPs 
recovery in [RFC4872] and segment recovery in [RFC4873].  GMPLS 
segment recovery provides a superset of the function in end-to-end 
recovery.  End-to-end recovery can be viewed as a special case of 
segment recovery where there is a single recovery domain whose 
borders coincide with the ingress and egress of the LSP, although 
Specific procedures are defined. 
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The five defined types of recovery defined in GMPLS are: 


- 1+1 bidirectional protection for P2P LSPs 

- 1+1 unidirectional protection for P2MP LSPs 

- 1:n (including 1:1) protection with or without extra traffic 

- Rerouting without extra traffic (sometimes known as soft 
rerouting), including shared mesh restoration 

- Full LSP rerouting 


Recovery for MPLS-TP LSPs, as discussed in [RFC6372], is signaled 
using the mechanism defined in [RFC4872] and [RFC4873]. Note that 
when MEPs are required for the OAM CC function and the MEPs exist at 
LSP transit nodes, each MEP is instantiated at a hierarchical LSP end 
point, and protection is provided end-to-end for the hierarchical 
LSP. (Protection can be signaled using either [RFC4872] or [RFC4873] 
defined procedures.) The use of Notify messages to trigger 
protection switching and recovery is not required in MPLS-TP, as this 
function is expected to be supported via OAM. However, its use is 
not precluded. 


4.1.10.  Control-Plane Reference Points (E-NNI, I-NNI, UNI) 


The majority of RFCs about the GMPLS control plane define the control 
plane from the context of an internal Network-to-Network Interface 
(I-NNI). In the MPLS-TP context, some operators may choose to deploy 
signaled interfaces across User-to-Network Interfaces (UNIs) and 
across inter-provider, external Network-to-Network Interfaces 
(E-NNIs). Such support is embodied in [RFC4208] for UNIs and in 
[RFC5787] for routing areas in support of E-NNIs. This work may 
require extensions in order to meet the specific needs of an MPLS-TP 
UNI and E-NNI. 


4.2. OAM, MEP (Hierarchy), MIP Configuration and Control 


MPLS-TP is defined to support a comprehensive set of MPLS-TP OAM 
functions. The MPLS-TP control plane will not itself provide OAM 
functions, but it will be used to instantiate and otherwise control 
MPLS-TP OAM functions. 


Specific OAM requirements for MPLS-TP are documented in [RFC5860]. 
This document also states that it is required that the control plane 
be able to configure and control OAM entities. This requirement is 
not yet addressed by the existing RFCs, but such work is now under 
way, e.g., [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT]. 


Many OAM functions occur on a per-LSP basis, are typically in-band, 


and are initiated immediately after LSP establishment. Hence, it is 
desirable that such functions be established and activated via the 
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same control-plane signaling used to set up the LSP, as this 
effectively synchronizes OAM with the LSP lifetime and avoids the 
extra overhead and potential errors associated with separate OAM 
configuration mechanisms. 


4.2.1. Management-Plane Support 


There is no MPLS-TP requirement for a standardized management 
interface to the MPLS-TP control plane. That said, MPLS and GMPLS 
support a number of standardized management functions. These include 
the MPLS-TE/GMPLS TE Database Management Information Base [TE-MIB]; 
the MPLS-TE MIB [RFC3812]; the MPLS LSR MIB [RFC3813]; the GMPLS TE 
MIB [RFC4802]; and the GMPLS LSR MIB [RFC4803]. These MIB modules 
may be used in MPLS-TP networks. A general overview of MPLS-TP 
related MIB modules can be found in [TP-MIB]. Network management 
requirements for MPLS-based transport networks are provided in 
[RFC5951]. 


4.2.1.1. Recovery Triggers 

The GMPLS control plane allows for management-plane recovery triggers 
and directly supports control-plane recovery triggers. Support for 
control-plane recovery triggers is defined in [RFC4872], which refers 
to the triggers as "Recovery Commands". These commands can be used 
with both end-to-end and segment recovery, but are always controlled 
on an end-to-end basis. The recovery triggers/commands defined in 
[RFCA872] are: 

a. Lockout of recovery LSP 

b. Lockout of normal traffic 

c. Forced switch for normal traffic 

d. Requested switch for normal traffic 


e. Requested switch for recovery LSP 


Note that control-plane triggers are typically invoked in response to 
a management-plane request at the ingress. 


4.2.1.2. Management-Plane / Control-Plane Ownership Transfer 


In networks where both the control plane and management plane are 
provided, LSP provisioning can be done either by the control plane or 
management plane. As mentioned in the requirements section above, it 
must be possible to transfer, or handover, a management-plane-created 
LSP to the control-plane domain and vice versa.  [RFC5493] defines 
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the specific requirements for an LSP ownership handover procedure. 

It must be possible for the control plane to provide the management 
plane, in a reliable manner, with the status or result of an 
operation performed by the management plane. This notification may 
be either synchronous or asynchronous with respect to the operation. 
Moreover, it must be possible for the management plane to monitor the 
status of the control plane, for example, the status of a TE link, 
its available resources, etc. This monitoring may be based on 
queries initiated by the management plane or on notifications 
generated by the control plane. A mechanism must be made available 
by the control plane to the management plane to log operation of a 
control-plane LSP; that is, it must be possible from the NMS to have 
a clear view of the life (traffic hit, action performed, signaling, 
etc.) of a given LSP. The LSP handover procedure for MPLS-TP LSPs is 
supported via [RFC5852]. 


.3. GMPLS and MPLS-TP Requirements Table 


The following table shows how the MPLS-TP control-plane requirements 
can be met using the existing GMPLS control plane (which builds on 
the MPLS control plane). Areas where additional specifications are 
required are also identified. The table lists references based on 
the control-plane requirements as identified and numbered above in 
Section 2. 


* * * 

| Req # | References 

+------- pe a oe e edu + 

| 1 | Generic requirement met by using Standards Track RFCs | 

| 2 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | 

| 3 | [RFC5145] + Formal Definition (See Section 4.4.1) 

| 4 | Generic requirement met by using Standards Track RFCs | 

| 5 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | 

6 [RFC3471], [RFC3473], [RFC4875] 

| 7 | [RFC3471], [RFC3473] + 

| | Associated bidirectional LSPs (See Section 4.4.2) | 

| 8 | [RFC4875] | 

| 9 | [RFC3473] | 

| 10 | Associated bidirectional LSPs (See Section 4.4.2) | 
11 Associated bidirectional LSPs (See Section 4.4.2) 

| 12 | [RFC3473] | 

| 13 | [RFC5467] (Currently Experimental; See Section 4.4.3) | 

| 14 | [RFC3945], [RFC3473], [RFC4202], [RFC4203], [RFC5307] | 

| 15 | [RFC3945], [RFC3473], [RFC4202], [RFC4203], [RFC5307] | 

| 16 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | 

| 17 | [RFC3945], [RFC4202] + proper vendor implementation | 
18 [RFC3945], [RFC4202] + proper vendor implementation 

| 19 | [RFC3945], [RFC4202] 
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(see Sec. 


4.4.4) 
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[RFC4872], 
[RFC4872], 
[RFC4872], 
[RFC4872], 
[RFC4872], 
[RFC3473], 
[RFC3473] 

[RFC3473], 
[RFC3473], 
[RFC4872], 
[RFC4426], 
[RFC4426], 
[RFC4426], 
[RFC4426], 
[RFC4426], 
[RFC4426], 
[RFC4426], 
[RFC4426], 
[RFC4872], 
[RFC4872], 
[RFC4872], 
[RFC4872], 
[RFC4872], 
[RFC4872], 
[RFC4872], 
[RFC4872], 
[RFC4872], 
[RFC3270], 
[RFC3945], 
[RFC3945], 


[RFC3473], 
[RFC3270], 


[RFC3945], 
[RFC3945], 


[RFC3473], 
[RFC4872], 
[RFC3945], 


[RFC3473], 


[RFC3473], 


et al. 


[RFC4873] 
[RFC4873] 
[RFC4873] 
[RFC4873], [RFC6107] 
[RFC4873] 
[RFC4872], [RFC4873] 


[RFC4872], [GMPLS-PS] 
[RFC4872] 
[RFC4873], [CCAMP-OAM-FWK], 
[RFC4872], [RFC4873] 
[RFC4872], [RFC4873] 
[RFC4872], [RFC4873] 
[RFC4872], [RFC4873] 
[RFC4872], [RFC4873] 


[RFC4872], [RFC4873] + vendor implementation 


[RFC4872], [RFC4873] 
[RFC4872], [RFC4873] 
[RFC4873] + Testing control 
[RFC4873] + Testing control 
[RFC4873] + Testing control 
[RFC4873] + Testing control 
[RFC4873], [CCAMP-OAM-FWK], 
[RFC4873] 

[RFC4873] 

[RFC4873], [TP-RING] 
[RFC4873], [TP-RING] 


[RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) 
[RFC4202], [RFC3473], [RFC4203], [RFC5307] 
[RFC3473], [RFC2210], [RFC2211], [RFC2212] 
Generic requirement on data plane 


[NO-PHP ] 


[RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) 
PW only requirement; see PW Requirements Table (5.2) 
PW only requirement; see PW Requirements Table (5.2) 


[RFC3473], [RFC6107] 


[RFC4202], [RFC3473], [RFC4203], [RFC5307] + 
[RFC5392] and [RFC5316] 
PW only requirement; see PW Requirements Table (5.2) 
[RFC4203], [RFC5307], [RFC5063] 


[RFC4873], [TP-RING] 
[RFC3473], [RFC6107] 


[CCAMP-OAM-FWK], [CCAMP-OAM-EXT] 
[CCAMP-OAM-FWK], [CCAMP-OAM-EXT] 
[CCAMP-OAM-FWK], [CCAMP-OAM-EXT] 
[CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) 
[CCAMP-OAM-FWK], [CCAMP-OAM-EXT] 


[RFC4872], [RFC4873] 


Informational 


(correct implementation) 


September 2011 


[CCAMP-OAM-EXT] 


(See Sec. 4.4.5) 
(See Sec. 4.4.5) 
(See Sec. 4.4.5) 
(See Sec. 4.4.5) 


[CCAMP-OAM-EXT 
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| 110 | [RFC3473], [RFC4872], [RFC4873] 
| 111 | [RFC3473], [RFC4783] 
| 112 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] 
1:13 [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) 
| 114 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | 
| 115 | [RFC3473] | 
| 116 | [RFC4426], [RFC4872], [RFC4873] 
| 117 | [RFC3473], [RFC4872], [RFC4873] 
118 [RFC3473], [RFC4783] 
| 119 | [RFC3473] | 
| 120 | [RFC3473], [RFC4783] 
| 121 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | 
| 122 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | 
| 123 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT], [RFC6107] 
| 124 - | | 
| 135 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) 
136a [RFC3473] 
| 136b | [RFC3473] + (See Sec. 4.4.7) 
| 137a | [RFC3473] | 
| 137b | [RFC3473] + (See Sec. 4.4.7) 
| 138 | PW only requirement; see PW Requirements Table (5.2) | 
139 - 
143 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.8) 
+ + + 
Table 1: GMPLS and MPLS-TP Requirements Table 
4.4. Anticipated MPLS-TP-Related Extensions and Definitions 
This section identifies the extensions and other documents that have 
been identified as likely to be needed to support the full set of 
MPLS-TP control-plane requirements. 
4.4.1. MPLS-TE to MPLS-TP LSP Control-Plane Interworking 
While no interworking function is expected in the data plane to 
support the interconnection of MPLS-TE and MPLS-TP networking, this 
is not the case for the control plane.  MPLS-TE networks typically 
use LSP signaling based on [RFC3209], while MPLS-TP LSPs will be 
signaled using GMPLS RSVP-TE, i.e., [RFC3473]. [RFC5145] identifies 
a set of solutions that are aimed to aid in the interworking of MPLS- 
TE and GMPLS control planes. [RFC5145] work will serve as the 
foundation for a formal definition of MPLS to MPLS-TP control-plane 
interworking. 
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4.4.2. Associated Bidirectional LSPs 


GMPLS signaling, [RFC3473], supports unidirectional and co-routed, 
bidirectional point-to-point LSPs.  MPLS-TP also requires support for 
associated bidirectional point-to-point LSPs. Such support will 
require an extension or a formal definition of how the LSP end points 
supporting an associated bidirectional service will coordinate the 
two LSPs used to provide such a service. Per requirement 11, transit 
nodes that support an associated bidirectional service should be 
aware of the association of the LSPs used to support the service when 
both LSPs are supported on that transit node. There are several 
existing protocol mechanisms on which to base such support, 
including, but not limited to: 


o GMPLS calls [RFC4974]. 
o The ASSOCIATION object [RFC4872]. 
o The LSP TUNNEL INTERFACE ID object [RFC6107]. 
4.4.3. Asymmetric Bandwidth LSPs 
[RFC5467] defines support for bidirectional LSPs that have different 
(asymmetric) bandwidth requirements for each direction. That RFC can 
be used to meet the related MPLS-TP technical requirement, but it is 


currently an Experimental RFC. To fully satisfy the MPLS-TP 
requirement, RFC 5467 will need to become a Standards Track RFC. 


4.4.4. Recovery for P2MP LSPs 


The definitions of P2MP, [RFC4875], and GMPLS recovery, [RFC4872] and 
[RFC4873], do not explicitly cover their interactions.  MPLS-TP 
requires a formal definition of recovery techniques for P2MP LSPs. 
Such a formal definition will be based on existing RFCs and may not 
require any new protocol mechanisms but, nonetheless, must be 
documented. 


4.4.5. Test Traffic Control and Other OAM Functions 


[CCAMP-OAM-FWK] and [CCAMP-OAM-EXT] are examples of OAM-related 
control extensions to GMPLS. These extensions cover a portion of, 
but not all, OAM-related control functions that have been identified 
in the context of MPLS-TP. As discussed above, the MPLS-TP control 
plane must support the selection of which OAM function(s) (if any) to 
use (including support to select experimental OAM functions) and what 
OAM functionality to run, including Continuity Check (CC), 
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4. 


4 


Du 


Dis 


Connectivity Verification (CV), packet loss, delay quantification, 
and diagnostic testing of a service. Such support may be included in 
the listed documents or in other documents. 


4.6. Diffserv Object Usage in GMPLS 


[RFC3270] and [RFC4124] define support for Diffserv-enabled MPLS 
LSPs. While [RFC4124] references GMPLS signaling, there is no 
explicit discussion on the use of the Diffserv-related objects in 
GMPLS signaling. A (possibly Informational) document on how GMPLS 
supports Diffserv LSPs is likely to prove useful in the context of 
MPLS-TP. 


-4.7. Support for MPLS-TP LSP Identifiers 


MPLS-TP uses two forms of LSP identifiers, see [RFC6370]. One form 
is based on existing GMPLS fields. The other form is based on either 
the globally unique Attachment Interface Identifier (AII) defined in 
[RFC5003] or the ITU Carrier Code (ICC) defined in ITU-T 
Recommendation M.1400. Neither form is currently supported in GMPLS, 
and such extensions will need to be documented. 


.4.8. Support for MPLS-TP Maintenance Identifiers 


MPLS-TP defines several forms of maintenance-entity-related 
identifiers. Both node-unique and global forms are defined. 
Extensions will be required to GMPLS to support these identifiers. 
These extensions may be added to existing works in progress, such as 
[CCAMP-OAM-FWK] and [CCAMP-OAM-EXT], or may be defined in independent 
documents. 


Pseudowires 
1. LDP Functions and Pseudowires 


MPLS PWs are defined in [RFC3985] and [RFC5659], and provide for 
emulated services over an MPLS Packet Switched Network (PSN). 

Several types of PWs have been defined: (1) Ethernet PWs providing 
for Ethernet port or Ethernet VLAN transport over MPLS [RFCA4448], (2) 
High-Level Data Link Control (HDLC) / PPP PW providing for HDLC/PPP 
leased line transport over MPLS [RFC4618], (3) ATM PWs [RFC4816], (4) 
Frame Relay PWs [RFC4619], and (5) circuit Emulation PWs [RFC4553]. 


Today's transport networks based on Plesiochronous Digital Hierarchy 
(PDH), WDM, or SONET/SDH provide transport for PDH or SONET (e.g., 
ATM over SONET or Packet PPP over SONET) client signals with no 
payload awareness. Implementing PW capability allows for the use of 
an existing technology to substitute the Time-Division Multiplexing 
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(TDM) transport with packet-based transport, using well-defined PW 
encapsulation methods for carrying various packet services over MPLS, 
and providing for potentially better bandwidth utilization. 


There are two general classes of PWs: (1) Single-Segment Pseudowires 
(SS-PWs) [RFC3985] and (2) Multi-segment Pseudowires (MS-PWs) 
[RFC5659]. An MPLS-TP network domain may transparently transport a 


PW whose end points are within a client network. Alternatively, an 
MPLS-TP edge node may be the Terminating PE (T-PE) for a PW, 
performing adaptation from the native attachment circuit technology 
(e.g., Ethernet 802.10) to an MPLS PW that is then transported in an 
LSP over an MPLS-TP network. In this way, the PW is analogous to a 
transport channel in a TDM network, and the LSP is equivalent to a 
container of multiple non-concatenated channels, albeit they are 
packet containers. An MPLS-TP network may also contain Switching PEs 
(S-PEs) for a Multi-Segment PW whereby the T-PEs may be at the edge 
of an MPLS-TP network or in a client network. In the latter case, a 
T-PE in a client network performs the adaptation of the native 
service to MPLS and the MPLS-TP network performs pseudowire 
switching. 


The SS-PW signaling control plane is based on targeted LDP (T-LDP) 
with specific procedures defined in [RFC4447]. The MS-PW signaling 
control plane is also based on T-LDP as allowed for in [RFC5659], 
[RFC6073], and [MS-PW-DYNAMIC]. An MPLS-TP network shall use the 
same PW signaling protocols and procedures for placing SS-PWs and 
MS-PWs. This will leverage existing technology as well as facilitate 
interoperability with client networks with native attachment circuits 
or PW segments that are switched across an MPLS-TP network. 


5.1.1. Management-Plane Support 


There is no MPLS-TP requirement for a standardized management 
interface to the MPLS-TP control plane. A general overview of MPLS- 


TP-related MIB modules can be found in [TP-MIB]. Network management 
requirements for MPLS-based transport networks are provided in 
[RFC5951]. 


5.2. PW Control (LDP) and MPLS-TP Requirements Table 


The following table shows how the MPLS-TP control-plane requirements 
can be met using the existing LDP control plane for pseudowires 
(targeted LDP). Areas where additional specifications are required 
are also identified. The table lists references based on the 
control-plane requirements as identified and numbered above in 
Section 2. 


Andersson, et al. Informational [Page 40] 


RFC 6373 MPLS-TP Control Plane Framework September 2011 


In the table below, several of the requirements shown are addressed 


-- in part or in full -- by the use of MPLS-TP LSPs to carry 
pseudowires. This is reflected by including "TP-LSPs" as a reference 
for those requirements. Section 5.3.2 provides additional context 


for the binding of PWs to TP-LSPs. 
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* * 
| Req # | References 
+------- 4----------------------------------------------------------- 
| 1 | Generic requirement met by using Standards Track RFCs 
| 2 | [RFC3985], [RFC4447], Together with TP-LSPs (Sec. 4.3) 
| 3 | [RFC3985], [RFC4447] 
| 4 | Generic requirement met by using Standards Track RFCs 
| 5 | [RFC3985], [RFC4447], Together with TP-LSPs 
6 [RFC3985], [RFC4447], [PW-P2MPR], [PW-P2MPE] + TP-LSPs 
| 7 | [RFC3985], [RFC4447], + TP-LSPs 
| 8 | [PW-P2MPR], [PW-P2MPE] 
| 9 | [RFC3985], end-node only involvement for PW 
| 10 | [RFC3985], proper vendor implementation 
| 11 | [RFC3985], end-node only involvement for PW 
| 12-13 | [RFC3985], [RFC4447], See Section 5.3.4 
14 [RFC3985], [RFC4447] 
| 15 | [RFC4447], [RFC3478], proper vendor implementation 
| 16 | [RFC3985], [RFC4447] 
| 17-18 | [RFC3985], proper vendor implementation 
| 19-26 | [RFC3985], [RFC4447], [RFC5659], implementation 
| 27 | [RFC4448], [RFC4816], [RFC4618], [RFC4619], [RFC4553] 
| | [RFC4842], [RFC5287] 
28 [RFC3985] 
| 29-31 | [RFC3985], [RFC4447] 
| 32 | [RFC3985], [RFC4447], [RFC5659], See Section 5.3.6 
| 33 | [RFC4385], [RFC4447], [RFC5586] 
| 34 | [PW-P2MPR], [PW-P2MPE] 
35 [RFC4863] 
| 36-37 | [RFC3985], [RFC4447], See Section 5.3.4 
| 38 | Provided by TP-LSPs 
| 39 | [RFC3985], [RFC4447], + TP-LSPs 
| 40 | [RFC3478] 
| 41-42 | [RFC3985], [RFC4447] 
43-44 [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.5 
45 [RFC3985], [RFC4447], [RFC5659] + TP-LSPs 
| 46 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.3 
| 47 | [PW-RED], [PW-REDB] 
| 48-49 | [RFC3985], [RFC4447], + TP-LSPs, implementation 
| 50-52 | Provided by TP-LSPs, and Section 5.3.5 
53-55 [RFC3985], [RFC4447], See Section 5.3.5 
| 56 | [PW-RED], [PW-REDB] 
| | revertive/non-revertive behavior is a local matter for PW 
| 57-58 | [PW-RED], [PW-REDB] 
| 59-81 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 
| 82-83 | [RFC5085], [RFC5586], [RFC5885] 
84-89 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 
| 90-95 | [RFC3985], [RFC4447], + TP-LSPs, implementation 
| 96 | [RFC4447], [MS-PW-DYNAMIC] 
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| 97 | [RFC4447] 
| 98 -=~ | 
99 Not Applicable to PW 
| 100 | [RFC4447] 
| 101 | [RFC3478] 
| 102 | [RFC3985], + TP-LSPs 
| 103 | Not Applicable to PW 
| 104 | [PW-OAM] 
| 105 | [PW-OAM] 
106 - 
| 108 | [RFC5085], [RFC5586], [RFC5885] 
| 109 | [RFC5085], [RFC5586], [RFC5885] 
| | fault reporting and protection triggering is a local 
| | matter for PW 
| 110 | [RFC5085], [RFC5586], [RFC5885] 
fault reporting and protection triggering is a local 
| | matter for PW 
| 111 | [RFC4447] 
| 112 | [RFC4447], [RFC5085], [RFC5586], [RFC5885] 
| 113 | [RFC5085], [RFC5586], [RFC5885] 
| 114 | [RFC5085], [RFC5586], [RFC5885] 
115 path traversed by PW is determined by LSP path; see 
| | GMPLS and MPLS-TP Requirements Table, Section 4.3 
| 116 | [PW-RED], [PW-REDB], administrative control of redundant 
| | PW is a local matter at the PW head-end 
| 117 | [PW-RED], [PW-REDB], [RFC5085], [RFC5586], [RFC5885] 
| 118 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 
119 [RFC4447] 
| 120 — | 
| 125 | [RFC5085], [RFC5586], [RFC5885] 
| 126 - | 
| 130 | [PW-OAM] 
| 131 | Section 543.5 
132 [PW-OAM] 
| 133 | [PW-OAM] 
| 134 | Section 5.3.5 
| 135 | [PW-OAM] 
| 136 | Not Applicable to PW 
| 137 | Not Applicable to PW 
| 138 | [RFC4447], [RFC5003], [MS-PW-DYNAMIC] 
139 - 
| 143 | [PW-OAM] 
* * 
Table 2: PW Control (LDP) and MPLS-TP Requirements Table 
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5.3.  Anticipated MPLS-TP-Related Extensions 


Existing control protocol and procedures will be reused as much as 
possible to support MPLS-TP. However, when using PWs in MPLS-TP, a 
set of new requirements is defined that may require extensions of the 
existing control mechanisms. This section clarifies the areas where 
extensions are needed based on the requirements that are related to 
the PW control plane and documented in [RFC5654]. 


Table 2 lists how requirements defined in [RFC5654] are expected to 
be addressed. 


The baseline requirement for extensions to support transport 
applications is that any new mechanisms and capabilities must be able 
to interoperate with existing IETF MPLS [RFC3031] and IETF PWE3 
[RFC3985] control and data planes where appropriate. Hence, 
extensions of the PW control plane must be in-line with the 
procedures defined in [RFCA4447], [RFC6073], and [MS-PW-DYNAMIC]. 


5.3.1. Extensions to Support Out-of-Band PW Control 


For MPLS-TP, it is required that the data and control planes can be 
both logically and physically separated. That is, the PW control 
plane must be able to operate out-of-band (OOB). This separation 
ensures, among other things, that in the case of control-plane 
failures the data plane is not affected and can continue to operate 
normally. This was not a design requirement for the current PW 
control plane. However, due to the PW concept, i.e., PWs are 
connecting logical entities ('forwarders'), and the operation of the 
PW control protocol, i.e., only edge PE nodes (T-PE, S-PE) take part 
in the signaling exchanges: moving T-LDP out-of-band seems to be, 
theoretically, a straightforward exercise. 


In fact, as a strictly local matter, ensuring that targeted LDP 
(I-LDP) uses out-of-band signaling requires only that the local 
implementation is configured in such a way that reachability for a 
target LSR address is via the out-of-band channel. 


More precisely, if IP addressing is used in the MPLS-TP control 
plane, then T-LDP addressing can be maintained, although all 
addresses will refer to control-plane entities. Both the PWid 
Forwarding Equivalence Class (FEC) and Generalized PWid FEC Elements 
can possibly be used in an OOB case as well. (Detailed evaluation is 
outside the scope of this document.) The PW label allocation and 
exchange mechanisms should be reused without change. 
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5.3.2. Support for Explicit Control of PW-to-LSP Binding 


Binding a PW to an LSP, or PW segments to LSPs, is left to nodes 
acting as T-PEs and S-PEs or a control-plane entity that may be the 
same one signaling the PW. However, an extension of the PW signaling 
protocol is required to allow the LSR at the signal initiation end to 
inform the targeted LSR (at the signal termination end) to which LSP 
the resulting PW is to be bound, in the event that more than one such 
LSP exists and the choice of LSPs is important to the service being 
setup (for example, if the service requires co-routed bidirectional 
paths). This is also particularly important to support transport 
path (symmetric and asymmetric) bandwidth requirements. 


For transport services, MPLS-TP requires support for bidirectional 
traffic that follows congruent paths. Currently, each direction of a 
PW or a PW segment is bound to a unidirectional LSP that extends 
between two T-PEs, two S-PEs, or a T-PE and an S-PE. The 
unidirectional LSPs in both directions are not required to follow 
congruent paths, and therefore both directions of a PW may not follow 
congruent paths, i.e., they are associated bidirectional paths. The 
only requirement in [RFC5659] is that a PW or a PW segment shares the 
same T-PEs in both directions and the same S-PEs in both directions. 


MPLS-TP imposes new requirements on the PW control plane, in 
requiring that both end points map the PW or PW segment to the same 
transport path for the case where this is an objective of the 
service. When a bidirectional LSP is selected on one end to 
transport the PW, a mechanism is needed that signals to the remote 
end which LSP has been selected locally to transport the PW. This 
would be accomplished by adding a new TLV to PW signaling. 


Note that this coincides with the gap identified for OOB support: a 
new mechanism is needed to allow explicit binding of a PW to the 
supporting transport LSP. 


The case of unidirectional transport paths may also require 
additional protocol mechanisms, as today's PWs are always 
bidirectional. One potential approach for providing a unidirectional 
PW-based transport path is for the PW to associate different 
(asymmetric) bandwidths in each direction, with a zero or minimal 
bandwidth for the return path. This approach is consistent with 
Section 3.8.2 of [RFC5921] but does not address P2MP paths. 


5.3.3. Support for Dynamic Transfer of PW Control/Ownership 
In order to satisfy requirement 47 (as defined in Section 2), it will 


be necessary to specify methods for transfer of PW ownership from the 
management to the control plane (and vice versa). 
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5.3.4. Interoperable Support for PW/LSP Resource Allocation 


Transport applications may require resource guarantees. For such 
transport LSPs, resource reservation mechanisms are provided via 
RSVP-TE and the use of Diffserv. If multiple PWs are multiplexed 
into the same transport LSP resources, contention may occur. 
However, local policy at PEs should ensure proper resource sharing 
among PWs mapped into a resource-guaranteed LSP. In the case of 
MS-PWs, signaling carries the PW traffic parameters [MS-PW-DYNAMIC] 
to enable admission control of a PW segment over a resource- 
guaranteed LSP. 


In conjunction with explicit PW-to-LSP binding, existing mechanisms 
may be sufficient; however, this needs to be verified in detailed 
evaluation. 


5.3.5. Support for PW Protection and PW OAM Configuration 


Many of the requirements listed in Section 2 are intended to support 
connectivity and performance monitoring (grouped together as OAM), as 
well as protection conformant with the transport services model. 


In general, protection of MPLS-TP transported services is provided by 
way of protection of transport LSPs. PW protection requires that 
mechanisms be defined to support redundant pseudowires, including a 
mechanism already described above for associating such pseudowires 
with specific protected ("working" and "protection") LSPs. Also 
required are definitions of local protection control functions, to 
include test/verification operations, and protection status signals 
needed to ensure that PW termination points are in agreement as to 
which of a set of redundant pseudowires are in use for which 
transport services at any given point in time. 


Much of this work is currently being done in documents [PW-RED] and 
[PW-REDB] that define, respectively, how to establish redundant 
pseudowires and how to indicate which is in use. Additional work may 
be required. 


Protection switching may be triggered manually by the operator, or as 
a result of loss of connectivity (detected using the mechanisms of 
[RFC5085] and [RFC5586]), or service degradation (detected using 
mechanisms yet to be defined). 


Automated protection switching is just one of the functions for which 
a transport service requires OAM. OAM is generally referred to as 
either "proactive" or "on-demand", where the distinction is whether a 
Specific OAM tool is being used continuously over time (for the 
purpose of detecting a need for protection switching, for example) or 
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is only used -- either a limited number of times or over a short 
period of time -- when explicitly enabled (for diagnostics, for 
example). 


PW OAM currently consists of connectivity verification defined by 
[RFC5085]. Work is currently in progress to extend PW OAM to include 
bidirectional forwarding detection (BFD) in [RFC5885], and work has 
begun on extending BFD to include performance-related monitor 
functions. 


5.3.6.  Client-Layer and Cross-Provider Interfaces to PW Control 


Additional work is likely to be required to define consistent access 
by a client-layer network, as well as between provider networks, to 
control information available to each type of network, for example, 
about the topology of an MS-PW. This information may be required by 
the client-layer network in order to provide hints that may help to 
avoid establishment of fate-sharing alternate paths. Such work will 
need to fit within the ASON architecture; see requirement 38 above. 


5.4. ASON Architecture Considerations 


MPLS-TP PWs are always transported using LSPs, and these LSPs will 
either have been statically provisioned or signaled using GMPLS. 


For LSPs signaled using the MPLS-TP LSP control plane (GMPLS), 
conformance with the ASON architecture is as described in Section 1.2 
("Basic Approach"), bullet 4, of this framework document. 


As discussed above in Section 5.3, there are anticipated extensions 
in the following areas that may be related to ASON architecture: 


- PW-to-LSP binding (Section 5.3.2) 

- PW/LSP resource allocation (Section 5.3.4) 

- PW protection and OAM configuration (Section 5.3.5) 

- Client-layer interfaces for PW control (Section 5.3.6) 


This work is expected to be consistent with ASON architecture and may 
require additional specification in order to achieve this goal. 


6. Security Considerations 
This document primarily describes how existing mechanisms can be used 
to meet the MPLS-TP control-plane requirements. The documents that 


describe each mechanism contain their own security considerations 
sections. For a general discussion on MPLS- and GMPLS-related 
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security issues, see the MPLS/GMPLS security framework [RFC5920]. As 
mentioned above in Section 2.4, there are no specific MPLS-TP 
control-plane security requirements. 


This document also identifies a number of needed control-plane 
extensions. It is expected that the documents that define such 
extensions will also include any appropriate security considerations. 
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